home *** CD-ROM | disk | FTP | other *** search
/ Power Tools 1993 November - Disc 2 / Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso / hotlines / gsyhl / cosev4.txt < prev    next >
Text File  |  1993-10-05  |  5KB  |  103 lines
  1. Implications of the recent COSE industry announcement on System V.4
  2. ===================================================================
  3.  
  4.  
  5. Two appoaches to Unix based standards
  6. _____________________________________
  7.  
  8. Over the last couple of years a number of participants within the
  9. Unix(TM) Industry have attempted to define Unix based standards
  10. in terms of a particular IMPLEMENTATION of the operating system,
  11. such as System V.4 (eg. USL) and OSF/1 (eg. DEC).  "Implementation"
  12. meaning the actual SOURCE code of the kernel.
  13.  
  14. Other vendors, including HP, have continued to support the definition
  15. of Unix based standards in terms of Application Programming
  16. Interfaces (API).  As a consequence HP has aggressively implemented
  17. key standards based API definitions such as XPG/4, SVID 2 and OSF's
  18. AES into HPUX and was already planning SVID 3 Level 1 compliance in 1994
  19. (the API definition for System V.4).
  20.  
  21. The benefits and flaws of each approach
  22. _______________________________________
  23.  
  24. The advantage of the "API based" standards approach is that each
  25. vendor can optimise performance and provide additional functionality
  26. (eg. High Availability) WITHOUT sacrificing application portability,
  27. as long as a single, common set of APIs exists.  However, until
  28. recently, this approach was flawed because of the existence of multiple
  29. API standards with individual vendors offering different subsets of
  30. these APIs.  In practice, this inhibited portability.
  31.  
  32. Proponents of the "implementation based" standards approach believed
  33. that the way to solve the portability issue was to demand that all
  34. vendors used one source code implementation (and therefore one API).
  35. However this approach had many flaws.  Innovation in performance
  36. and functionality, available in the "API" approach, was severely
  37. limited by the "implementation based" strategy.  Ownership of the
  38. source code by a single vendor provided the threat of industry
  39. dominance which can ultimately harm customers' interests.  Worse still,
  40. the portability goal was unachievable because there were MULTIPLE,
  41. competing implementations (eg V.4, OSF/1), each with their own API set.
  42.  
  43. Users and developers forced to "bet"
  44. ____________________________________
  45.  
  46. In this confused environment, both software developers and customers
  47. were required to make two "bets".  First, should they support the
  48. "implementation" or "API" approach to Unix standards in their own
  49. requirements specifications?  Second, having chosen the approach,
  50. which "standard" should they choose? (eg. "V.4 vs OSF/1" or
  51. "XPG/4 vs AES vs SVID").
  52.  
  53. Industry resolution of the portability problem
  54. ______________________________________________
  55.  
  56. With the recent 1st September COSE announcement, an overwhelming
  57. majority of industry participants, including software developers and
  58. customer representatives, resolved this issue.  The direction chosen
  59. is the "API based" approach and agreement has been reached on the
  60. SINGLE, Common OS API set which will finally offer true, industry-wide
  61. portability.
  62.  
  63. Ownership of this Common OS API set will be with X/Open, preventing
  64. single vendor dominance.  The standard will succeed where previous API
  65. standards have failed by providing a set of APIs that has been tested
  66. against 50 real life applications, offering meaningful "completeness".
  67. Furthermore, with the support of almost all major industry participants,
  68. the standard will become pervasive.  Portability will be achieved
  69. whilst protecting the innovation available from an "API based" approach
  70. to Unix based standards.
  71.  
  72. The implications for System V.4
  73. _______________________________
  74.  
  75. Novell/USL's strong participation in this COSE process and support
  76. for X/Open's control of the "API based" standards approach has
  77. effectively signalled the end to USL's previous policy of driving
  78. for an "implementation based" approach, centred on System V.4.
  79.  
  80. In effect System V.4 has become IRRELEVANT as a Unix based standard.
  81.  
  82. The implication for end users and software developers alike is that
  83. they should start to withdraw System V.4 from their requirement
  84. specifications and start replacing it with the API specifications
  85. that will eventually become XPG4+ (ie the Common OS API set based
  86. on a superset of XPG4, AES and SVID3 Level 1).
  87.  
  88. Furthermore, customers and software partners should recognise that
  89. maintaining a commitment to System V.4 as a requirement specification
  90. may actually lead them down a path that moves AWAY from industry-wide
  91. compatability and DENIES them the benefits available from functionality
  92. and performance innovations that will be delivered by the rest of the
  93. Unix industry.
  94.  
  95. Hewlett-Packard: The Open Systems Trusted Advisor
  96. _________________________________________________
  97.  
  98. After leading the COSE efforts towards the unification of Unix and
  99. having our support for an "API based" approach to industry standards
  100. substantiated, Hewlett-Packard is in a strong position to support software
  101. developers and end users in their move towards the new XPG4+ standards
  102. environment.  HP continues to demonstrate its leadership position as
  103. the Open Systems Trusted Advisor.